3 Design Considerations for Effective Mobile-App Permission Requests應用許可權請求
移動應用的許可權請求設計往往較差，常導致使用者困惑或反感。設計良好的許可權請求應注重內容與時機，避免暗黑模式，並支援使用者輕鬆撤回之前的決定。
什麼是許可權請求？
許可權請求是應用在訪問使用者裝置資源（如相機、地理位置或麥克風）前向使用者提出的授權對話方塊，形式由作業系統決定，但設計影響使用者是否接受請求。
許可權請求的意義在於：
- 保護使用者隱私: 賦予使用者對敏感資料的控制權。
- 增強信任感: 使用者需要信任應用不會惡意利用資源。
儘管iOS和Android對許可權請求有一定設計指導，但許多應用的許可權請求依然存在以下問題：
- 缺乏合理的解釋。
- 請求時機不當。
- 不支援輕鬆撤回許可權。
許可權請求的三大設計考量
1. 許可權請求內容（Permission-Request Copy）
A 好的內容提升接受率
研究表明，當許可權請求中明確說明請求原因時，使用者接受率平均提高12%。
案例分析:
Instagram: 請求訪問照片庫時清楚表明可“分享照片”和“儲存編輯後的照片”，突出了使用者收益。
United Airlines: 文案含糊（如“掃描旅行檔案”），且無明確使用者收益，易引發使用者懷疑。
B 如何撰寫有效文案
- 避免技術術語: 用使用者能理解的簡單語言表述。
- 強呼叫戶收益: 闡明允許許可權對使用者的直接好處，而非僅列出依賴許可權的功能。
OK: Snapchat需要訪問您的相機以拍攝照片。
更好: 允許Snapchat訪問您的相機，這樣您可以拍攝照片並與好友分享。
- 避免含糊措辭: 如“提升使用者體驗”這樣的空洞承諾。
C 針對Android的額外設計建議
Android系統缺少iOS的“目的字串”（Purpose String），設計時應增加前置螢幕，提前解釋請求理由。
Any.do 應用在許可權請求前透過介紹屏解釋其訪問聯絡人許可權的價值，如提醒使用者回撥重要電話。
2. 許可權請求的時機（Timing of the Permission Request）
A 上下文相關的許可權請求
使用者在執行與許可權直接相關的操作時（如點選麥克風按鈕觸發錄音許可權），此類請求顯得自然且合理。
示例:Waze: 使用者點選麥克風按鈕時彈出錄音許可權請求，顯得直觀且預期明確。
B 系統觸發的許可權請求
使用者首次開啟應用時可能遇到多個許可權請求，這種情況下常因缺乏上下文而顯得突兀。
示例:Viber: 使用者首次啟動應用時連續彈出5個許可權請求，容易引發使用者疲勞和反感。
C 最佳化許可權請求時機
避免在首次安裝後立即請求所有許可權，只請求核心功能所需許可權。
在使用者嘗試使用特定功能時再請求相關許可權，這樣能提供清晰的上下文支援。
在請求非關鍵許可權前先提供價值，讓使用者瞭解其意義和好處。
3. 許可權撤回的支援（Decision Reversal for Permissions）
使用者可能初次拒絕許可權，但隨後希望重新開啟。設計時應：
- 清楚說明原因: 當功能因許可權被拒絕而不可用時，明確解釋缺失許可權對功能的影響。
- 提供連結: 引導使用者到裝置設定頁面快速調整許可權。
案例分析:Venmo: 當相機許可權被拒絕時，顯示錯誤提示並附上“開啟設定”連結，直達許可權設定頁面。唯一改進點是讓連結樣式更明顯，以避免使用者誤以為是普通文字。
避免暗黑模式（Dark Patterns）
部分應用使用暗黑模式誘導使用者同意許可權請求
WeChat: 將許可權請求偽裝為資訊對話方塊，推薦“OK”選項，同時隱藏拒絕選項。這種做法不僅不符合道德，也容易破壞使用者信任。
建議:
提供足夠的資訊讓使用者自由選擇。
尊重使用者決策，並透過易用的撤回設計支援使用者改變主意。
有效的許可權請求設計需要：
- 內容清晰: 使用易懂的語言突出使用者收益，避免含糊或技術術語。
- 時機合理: 在合適的上下文中發起請求，避免在使用者忙於其他任務時打斷。
- 支援撤回: 提供簡單直觀的方式，讓使用者隨時調整許可權設定。
遵循以上原則能增強使用者對應用的信任，同時減少許可權請求帶來的困擾，進而提升整體使用者體驗。